I was just noticing in #246 that get-dag doesn't seem quite right so went about trying to address it, then in the process I'm realising that I don't have much use for CARv2 with much of the stuff I'm interested in and not having the option to make v1 CARs is a bit annoying, so I added a -version to it as well.

The current form seems to write out every matching node in a selector, not block, which will get pretty gnarly with complex blocks and a match-all and likely not what the user wants. This version uses the selector for the walk only (so it can be an explore, not a match) and uses the block loader to indicate what blocks are visited. It's not entirely unreasonable that a user may want to match individual nodes and turn them into blocks, but I think it's very unlikely desired behaviour and they're thinking in terms of whole blocks contained within the DAG described by a selector that will walk that DAG.

This needs tests, the sample v1 and wrapped v2 are kind of funky, with inlines and some weird stuff that I'm not sure how to account for properly in tests so I was thinking about making a simple DAG that can have selectors run over.

I also wanted to get the same thing for ipfs dag export which is exclusively CARv1 (atm anyway): ipfs/kubo#8506 - I was making way for selectors in there too but figure that maybe this is the best place to experiment with some of that crazy, including questions of what to do with excessively linked DAGs that make the traversal too onerous.